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(57) Abstract: In general, techniques are described that facilitate the reuse of software assets within an enterprise. A software asset, 
as used herein, refers to a set of one or more related artifacts that have been created or harvested for the purpose of applying that 
asset repeatedly in subsequent development environments. A system, for example, is described that includes a repository (4A) to 
store artifacts, and an asset source (12A) to generate a software asset based on the artifacts. The system further includes an asset 
management system (6) to receive the software asset from the asset source (12A) and store the software asset within an asset library 
(36). The system may furthfer include a model (37) having one or more elements, and an asset retrieval module (42) to selectively 
retrieve a subset of the software assets from the asset library (36) based on input from a user identifying one or more of the elements. 
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MANAGING REUSABLE SOFTWARE ASSETS 

TECHNICAL FIELD 

The invention relates to computer software, and more particularly, 
5 managing reusable software assets. 

BACKGROUND 

Over the past several years, software development efforts within enterprises 
have grown tremendously, resulting in large volumes of software code, 

10 documentation, models, and other related artifacts. A large enterprise, for example, 
may have a significant number of ongoing software development projects at any 
one time ranging in size from small projects involving a handful of programmers to 
massive endeavors involving hundreds of programmers. 

In the past few years, there has been a tremendous amount of work in the 

1 5 area of software engineering and, in particular, the reuse of software across 

development projects. Reusing software can have significant advantages in, for 
example, reducing the resources, expense, and development time for a software 
project. Identifying artifacts for reuse from the various repositories of a given 
enterprise, however, can be a complex task. In addition to the problems involved 

20 in identifying a potentially massive number of artifacts, the artifacts are typically 
stored within repositories dispersed throughout the enterprise, and maintained by 
specialized development or operational environments. 

SUMMARY 

25 In general, the invention is directed to techniques that facilitate the reuse of 

software assets within an enterprise. A software asset, as used herein, refers to a 
set of one or more related artifacts that have been created or harvested for the 
purpose of applying that asset repeatedly in subsequent development 
environments. Source code and binary code are examples of artifacts for software 

30 assets. Other examples of artifacts include related documentation, such as 

requirement specifications, design documents, operation manuals, and the like. 
Additional examples of artifacts include models, such as a process model, 
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structural model, resource model, implementation model, and the like, that may 
include use cases, object models, collaboration diagrams, deployment models, and 
the like. 

In one embodiment, a system comprises a repository to store artifacts, and 
5 an asset source to generate a software asset based on the artifacts. The system 

further comprises an asset management system to receive the software asset from 
the asset source and to store the software asset within an asset library. 

In another embodiment, a system comprises a plurality of repositories to 
store artifacts, and asset templates that define schemas for reusable software assets 

10 in accordance with a data description language. The system further comprises a 
plurality of asset sources to monitor the repositories and generate software assets 
having metadata that reference the artifacts in accordance with schemas of the 
asset templates, and an asset management system to receive the software assets 
from the asset sources and store the software assets within an asset library. 

1 5 In another embodiment, a system comprises a plurality of repositories to 

store artifacts, and a multi-level hierarchy of asset sources to generate software 
assets having metadata that reference the artifacts. The higher-level asset sources 
of the hierarchy receive software assets from low-level asset sources of the 
hierarchy and form aggregate software assets. The system further comprises an 

20 asset management system to receive the aggregate software assets from the 

hierarchy of asset sources and store the aggregate software assets within an asset 
library. 

In another embodiment, a system comprises a model having one or more 
elements, and a database to store reusable software assets. The system further 
25 comprises an asset retrieval module to receive input from a user selecting an 

element of the model, and to selectively retrieve a subset of the software assets 
from the database based on the input. 

In another embodiment, a method comprises retrieving artifacts from 
repositories, and generating software assets based on the artifacts in a form that 
30 conforms to a data description language. The method further comprises publishing 
the software assets for storage within an asset library. 
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In another embodiment, a method comprises receiving input from a user 
selecting one or more elements of a model, and retrieving software assets from an 
asset library based on the selected elements. 

In another embodiment, a computer-readable medium comprises 
5 instructions to cause a processor to receive input from a user selecting one or more 
elements of a model, and retrieve software assets from an asset library based on the 
selected elements. 

In another embodiment, a computer-readable medium comprises data 
structures that store software models having elements, and software assets having 

10 metadata that maps the software asset to the elements of the software models. 

The techniques described herein may offer one or more advantages. For 
example, an enterprise may make use of distributed asset sources to provide 
generalized interfaces to diverse repositories, and to generate software assets in a 
normalized form that complies with a data description language. The software 

1 5 assets may be generated, for example, in accordance with one or more asset 
templates that define schemas for the assets. A user, such as a library 
administrator, may readily modify the asset templates to easily control the content 
and structure of the reusable software assets. This level of abstraction can be 
leveraged to automate or semi-automate the process of capturing artifacts from the 

20 repositories. In this manner, the asset management system provides users with a 
centralized asset library that offers a consistent, normalized view of the artifacts 
maintained over the many diverse repositories. In addition, an enterprise can make 
use of the system for bulk entry of assets, thereby simplifying and accelerating the 
process of capturing legacy software assets within the enterprise. 

25 The asset management system can be configured to provide a full range of 

asset capture activities, ranging from fully-automated asset capture to semi- 
automated or manual approaches that require at least some manual intervention 
during the capture process. Accordingly, the asset management system can be 
configured to automatically capture assets from the repositories and produce 

30 normalized assets, or to automatically require the augmentation of the assets with 
artifacts not present within the repositories. 
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Among many other possible advantages, the asset management system 
provides for the association of software assets captured from diverse repositories 
with elements of software models, such as a process model, a structural model, a 
resource model, an implementation model, and the like. Accordingly, users can 
develop specifications for software projects, for example, and easily identify 
reusable software assets within the asset library that may be leveraged for the 
project. 

The invention includes a targeted asset capture system that maps software 
resources to a domain model, and search and management tools for retrieving asset 
information and controlling asset acquisition. The domain model may include a 
process-centered organization and/or a structural organization of model tasks, 
functions, and data types. Capture includes mapping to the model functions and 
data types, and preferably also includes capturing other information about the asset 
and about the quality of mapping. The domain model may be used to build a 
search specification for searching for available assets that meet some or all of a set 
of functional (and/or nonfunctional) requirements. The search specification may 
also be published in part or in whole as a development specification. 

In one aspect, the invention comprises an asset capture software utility. 
The utility includes a database for cataloguing software resource information, and 
means for mapping functions and data types to a predetermined domain model. 
The domain model may be a two-part model comprising a process model and a 
structural model, which may be linked to one another. There may be multiple 
process models for a single structural model. The utility may use synonyms to 
suggest mappings to the domain model. The mapping means may include means 
for adding user comments, such as comments on the character or quality of the 
mapping or on the usage or purpose of certain functions and data types. 

In another aspect, the invention comprises a database of resource 
information, where the resource information includes functionality information 
mapped to a predetermined domain model. The database may include a search 
engine, for example an engine that can score resources according to how well they 
match functional or nonfunctional requirements. The search engine may include 
means for creating a persistent search specification that can be used by multiple 
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users. Individual resources maybe attached to the search specification for 
consideration. The search specification may be publishable, in whole or in part, as 
a requirements specification for software development. The search engine may 
notify one or more users of additions to the database that match a persistent search 
5 specification. Functionality infonnation may be mapped over multiple domain 
models. The database may include means for viewing the domain model (e.g., 
graphically) in order to specify a search. The means may include means of 
navigating between process-side and structural-side of a domain model. The 
database may also include resource usage information, which may be linked to 

1 0 projects and may include information such as licensing data, resource acquisition 
tools, and usage reporting tools. 

In a further aspect, the invention includes methods of classifying resources 
against a domain model, by mapping resource data types to model data types and 
resource functions to model functions, and storing the results in a searchable 

1 5 database. The domain model may include a process model and a structural model, 
which may be linked together. Multiple process models may also be linked to a 
single structural model. The method may include using synonyms to search model 
function and data type descriptions. Comments may be added to the database, for 
example on the quality of the mapping or on individual function or data type usage 

20 or purposes. The method may also include forwarding asset acquisition requests to 
an acquirer and storing acquisition information such as license keys. The method 
may also include generating usage reports or acquisition request reports. 

In still another aspect, the invention includes methods of managing 
resources within an enterprise, by maintaining a searchable database of resource 

25 information including location information and functionality information, the 
functionality information being mapped to a domain model. The methods may 
include searching the database for resources that match functional or nonfunctional 
requirements, for example by creating a persistent search specification. A 
persistent search specification may be shared between users and/or published as a 

30 requirements document. Assets may be attached to the persistent search 
specification, and the method may include publishing the portions of the 
specification that are not matched by the attached assets. One or more users may 
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also be notified when resources are added to the database that match the persistent 
search specification. The method may further include forwarding requests for 
resource acquisition to an acquirer, and storing acquisition information such as 
license keys. The method may also include generating reports on acquisition 
requests and/or resource usage. 

In yet another aspect, the invention includes methods of mapping software 
resources to a domain reference model, including determining functions and data 
types to be mapped, sorting them into an order from most simple to most complex, 
and presenting them to a user in the determined order for mapping. As the user is 
presented with individual functions and data types, previously created mappings 
are used to refine further mapping suggestions. The determined order may include, 
for example, viewing all data types before viewing functions. The user may elect 
to map functions and data types in a different order. 

The details of one or more embodiments of the invention are set forth in the 
accompanying drawings and the description below. Other features, objects, and 
advantages of the invention will be apparent from the description and drawings, 
and from the claims. 

BRIEF DESCRIPTION OF DRAWINGS 

FIG. 1 is a block diagram illustrating an example system that facilitates the 
reuse of assets within an enterprise generally. 

FIG. 2 is a block diagram illustrating an example embodiment of an asset 
management system. 

FIG. 3 is a block diagram illustrating an example embodiment of an asset 

source. 

FIG. 4 is a flowchart illustrating in further detail the interactions between 
the asset management system and the asset sources to facilitate the reuse of assets 
within an enterprise. 

FIG. 5 is a block diagram illustrating an asset source hierarchy. 

FIG. 6 is a block diagram illustrating in further detail one embodiment of 
an asset capture module of the asset management system 
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FIG. 7 is a flowchart further illustrating an example mode of operation of 
the asset capture module. 

FIG. 8 is a flowchart illustrating an example of retrieving reusable assets 
from the asset management system. 

FIG. 9 is a top-level diagram of an insurance domain reference model 
(DRM). 

FIG. 10 is an expansion of the Remediation category of the DRM of FIG. 9. 
FIG. 1 1 shows a portion of a use case diagram from the insurance DRM. 
FIG. 12 shows functions identified as part of a step of the use case of FIG. 

11. 

FIG. 13 is a window showing Classification according to one embodiment 
of the invention. 

FIG. 14 is a window showing Model Capture. 

FIG. 15 is a window showing selection of Diagram options. 

FIG. 16 is a window showing capture of an asset Interface. 

FIG. 17 is a window showing identification of external Data Types. 

FIG. 18 is a window showing an interface diagram for a Currency 
Management asset. 

FIG. 19 is a window showing entry of artifacts for an asset. 

FIG. 20 is a window showing entry of Asset Synonyms. 

FIG. 21 is a window showing selection of a Reference Model. 

FIG. 22 is a window showing Synonyms for the DRM and Library. 

FIG. 23 is a window showing Datatype mapping. 

FIG. 24 is a window showing entry of descriptors of mapping quality. 

FIG. 25 is a window showing a completed Datatype mapping. 

FIG. 26 is a window showing a constructed search specification using 
DRM functions. 

FIG. 27 is a window showing a constructed search specification using 
keywords. 

FIG. 28 is a window showing a search result. 
FIG. 29 is a window showing attachment of resources to a search 
specification. 
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FIG. 30 is a window showing a detailed view of an attached asset. 
FIG. 3 1 is a flow chart showing the process for submitting an asset for 
acquisition. 

FIG. 32 is a window showing pending acquisition requests. 
5 FIG. 33 is a window showing the details of requests for a pending asset. 

FIG. 34 is an asset acquisition screen. 
FIG. 35 is a window showing an asset usage summary. 



DETAILED DESCRIPTION 

10 FIG 1 is a block diagram illustrating an example system 2 that facilitates 

the reuse of software assets within an enterprise generally. In general, a reusable 
software asset, as used herein, refers to a set of related artifacts that have been 
created or harvested for the purpose of applying that asset repeatedly in subsequent 
development environments. Examples of artifacts for software assets include the 

1 5 source code or binary code for the software asset. Other examples include 

documentation such as a requirements specification, design document, and the like. 
Additional examples of artifacts include use cases, object models, collaboration 
diagrams, deployment models, and the like. Further examples include operational 
artifacts deployed within operational environments of the enterprise, such as 

20 component instances deployed within an application server. 

Repositories 4A- 4N (herein repositories 4) represent any data source 
within an enterprise that stores information (herein artifacts) relevant to the 
management of reusable assets. Repository 4A may store, for example, reusable 
software components. These components are typically independently deployable 

25 code elements that often conform to a standardized component model, such as 
Enterprise JavaBeans (EJB) and the Component Object Model (COM). These 
components typically have well-defined interfaces that provide access to the 
encapsulated services or functions. An example of this type of repository includes 
a source code development environment that often stores the source code and the 

30 executable code within a repository to provide version control and to facilitate 
collaborative development. 



8 



WO 03/005243 



PCT/US02/20962 



As another example, repository 4B may store code elements that present 
functional interfaces to web services (web svcs) for remote access by client 
software via networking protocols, such as HTTP, HTTPS, FTP, SOAP, XML 
messaging, and the like. The enterprise may make use of these assets for quickly 

5 assembling web-based applications. One example of this type of software asset 

includes a server-side code element for providing web-based financial transactions. 

As another example, repository 4C may store schemas that conform to a 
data description language, such as XML, that can be used to assemble metadata for 
data transfer within the enterprise. Repository 4D may store modeling information 

10 (models) that provides formal representations of various software components. 
The modeling information may include use cases, object models, collaboration 
diagrams, deployment models, and the like. The modeling information may 
conform to the Unified Modeling Language (UML), for example. Repository 4N 
may store documentation related to the software components, including 

15 requirements specifications, design documents, and the like. 

In addition, the artifacts stored by repositories 4 are not limited to those 
artifacts generated during the development of the software components, but can 
encompass artifacts related to the deployment of the asset, such as particular 
instances of the software components. Accordingly, system 2 can be used to 

20 aggregate artifacts generated through the lifecycle of the asset, including artifacts 
generated during the development of the asset through the deployment of various 
instances of the asset, and artifacts generated through ongoing tracking of that asset 
within the operational environment. Examples of operational artifacts deployed 
within operational environments of the enterprise include component instances 

25 deployed within an application server. 

Repositories 4 may also comprise "active" repositories that manage data 
related to an asset in arbitrary form, and present "views" of that assemble the data 
into a consumable form. For example, a defect tracking system may manage any 
number of defects that can be organized into views related to specific assets, e.g., 

30 views that show only those defects pertinent to particular versions of assets under 
development. 
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Generally, these artifacts are likely developed and maintained within 
repositories 4 using specialized development tools. Accordingly, repositories 4 
may comprise a variety of storage facilities having very diverse interfaces. System 
2 makes use of one or more asset sources 12A-12N (herein asset sources 12) that 
5 provide a generalized, abstract interface to the underlying repositories 4. Asset 

sources 12 interact with repositories 4 to extract the artifacts, and assemble related 
artifacts to provide composite, normalized views of the reusable software assets. 
In particular, asset sources 12 generate asset descriptions that describe the related 
artifacts for each asset in a normalized form. 

10 Asset sources 12 output the software assets in a normalized form that 

complies with a data description language. In other words, the software assets 
include or reference artifact data from repository 4A, as well as metadata that 
conforms to the data description language. The data description language 
describes the format, organization and structure of the asset. Accordingly, the 

15 normalized assets produced by asset sources 12 may take the form of electronic 
documents, files, scripts, data streams, software objects, and the like, that contain 
the metadata conforming to the data description language. Other example 
languages include Extensible Style Language (XSL), Extensible Linking Language 
(XLL), Standardized Multimedia Authoring Language (SMIL), as well as 

20 variations of the Standard Generalized Markup Language (SGML). 

As described in detail below, users 8A can readily tailor each of asset 
sources 12 to the particular requirements of the corresponding one of repositories 
4. As described in detail below, users 8 may use asset definition templates to 
generically describe the normalized assets produced by asset sources 12. 

25 Asset management system 6 provides a centralized resource for collecting 

the asset descriptions from asset sources 12, and for publishing the asset 
descriptions to make the descriptions available to users 8A-8P (herein users 8) 
within the enterprise. More specifically asset management system 6 provides a 
comprehensive, searchable view of the software assets and related artifacts stored 

30 within the various repositories 4. By interacting with asset management system 6, 
users 8 can identify and make use of the assets. 



10 



WO 03/005243 



PCT/US02/20962 



System 2 may provide one or more advantageous features for capturing and 
managing reusable software assets. The use of asset sources 12 to provide a 
generalized interface to diverse repositories 4 can be leveraged to automate or 
semi-automate the process of capturing artifact information from repositories 4. 
5 Accordingly, an enterprise can make use of system 2 for bulk entry of assets, 
thereby simplifying and accelerating the process of capturing legacy software 
assets within the enterprise. In addition, asset management 6 and asset source 12 
provide users 8 with a consistent, normalized view of the artifacts maintained over 
the many diverse repositories 4. Furthermore, asset management system 6 and 

10 asset sources 12 may interact so as to provide a current view of repositories 4, even 
though repositories 4 may change over time. 

Furthermore, asset management system 6 and asset sources 12 can be 
configured to provide a full range of asset capture activities, ranging from fully- 
automated asset capture to semi-automated or manual approaches that requires at 

15 least some manual intervention of users 8 during the capture process. Accordingly, 
asset management system 6 and asset sources 12 automatically make available to 
users 8 assets that are automatically generated from repositories 4. In addition, 
asset management system 6 and asset sources 12 can be configured to allow users 
8 to augment the assets with artifacts not present within repositories 12 during the 

20 capture process. 

FIG. 2 is a block diagram illustrating an example embodiment of asset 
management system 6 of FIG. 1. Asset management system 6 comprises a number 
of cooperative modules that facilitate the management of reusable software assets. 
For example, asset management system 6 may include publishing module 

25 24 and asset capture module 26 that interact with asset sources 12 to collect and 
aggregate artifacts from repositories 4 (FIG. 1), such as asset source 12A and 
repository 4A, as illustrated for exemplary purposes in FIG. 2. Generally, asset 
source 12A collects and normalizes assets from repository 4A. In addition, asset 
source 12A provides an abstract interface for interaction with publishing module 

30 24 and asset capture module 26, thereby hiding the specific requirements of 
repository 4A from these modules. 
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In general, asset capture module 26 can augment the information extracted 
from repository 4A, and provides for resolution of conflicts between the extracted 
information and information required for publication of the asset by asset source 
12 A. Upon receiving notification 28 from asset source 12A indicating the 
5 availability of a new or updated asset, asset capture module 26 issues one or more 
messages 30 to asset source 12Ato retrieve the asset. Messages 30 may comprise, 
for example, Simple Object Access Protocol (SOAP) messages, Remote Method 
Invocation (RMI) calls, or any other mechanism for communication between 
modules. In addition, asset capture module 26 may access asset library 36 to 

10 retrieve a current instance of the asset being produced by asset source 12A. Asset 
capture module 26 may present the current instance of the asset as well as the asset 
produced by asset 12 A to user 39 for reconciliation. 

Asset source 12A and asset capture module 26 make use of asset templates 
47 to validate the asset information. In one embodiment, asset source 12 A, or a 

1 5 schema generation module, generates a virtual schema in accordance by applying 
asset templates 47 to a base schema for an asset. Asset templates conform to a 
data description language, such as the extensible markup language (XML), and 
may include definition templates and constraint templates. The base schema 
conforms to a schema definition language, and defines a class of elements that 

20 conform to the data description language. In this manner, the base schema may 
remain static and need not be modified to support new classes of assets. 

To define classes of permissible assets, a user, such as one of users 8 or 
library administrator 49, may create definition templates, constraint templates, or 
both. More specifically, the user may create one or more definition templates that 

25 define sub-classes for the elements defined by base schema. In this manner, the 
user can extend the element definitions of base schema without modifying base 
schema. 

In addition, the user may create one or more constraint templates that 
define requirements for instances of the elements. Constraint templates may define 
30 requirements for instances of elements belonging to the classes defined by base 
schema, instances of elements belonging to the sub-classes defined by definition 
templates, or both. For example, constraint templates may define a required 
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cardinality for the instances of the elements, a required minimum or maximum 
number of the instances, a range for a required number of the instances of the 
elements, a required attribute for the instances, a required parameter value for the 
instances of the elements, specific required instances of the elements, and the like. 
5 Asset source 12A generates the schema information of virtual schema by 

first generating a data structure representing the classes of elements defined by 
base schema. Asset source 12A then applies definition templates to base schema 
to extend the schema information to include the sub-classes of elements defined 
within definition templates. Finally, Asset source 12A applies constraint templates 
10 to update the schema information to include the restrictions defined by constraint 
templates. 

Definition templates and constraint templates conform to the data 
description language to which the elements of base schema comply, e.g., XML. 
Accordingly, the user can easily create and modify definition templates and 
1 5 constraint templates, and need only modify base schema in order to support new 
classes of assets. 

Asset source 12A and asset capture module 26 may use asset templates 47 
to drive the asset capture process. Based on the content and structure described by 
the asset schemas, which may be dynamically generated from asset templates 47, 

20 asset source 12A and asset capture module 26 identify any incomplete artifact data 
that needs to be added to the capture asset, either manually or in automated 
fashion. In this manner, asset source 12A can produce assets in a normalized form 
that complies with the schema information. The assets are normalized in the sense 
that the assets are described in a data description language, such as XML, and the 

25 elements and attributes are substantially similar. 

The following pseudocode illustrates an exemplary base schema, definition 
template and constraint template that maybe used for capturing information related 
to reusable software assets. In particular, the following exemplary base schema 
defines a parent class of elements named ASSET, and two child classes of elements 

30 named KEYWORD and RELATION. 

<XSD: SCHEMA > 

<XSD: ELEMENT NAME="ASSET"> 
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<XSD: ELEMENT NAME=" KEYWORD" MINOCCURS=" 0 " 
MAXOCCURS= " UNBOUNDED " > 

<XSD: ATTRIBUTE NAME= " NAME " TYPE="XSD : STRING" 
USE=" REQUIRED "/> 
5 <XSD: ATTRIBUTE NAME=" VALUE " TYPE-"XSD : STRING" 

USE="REQUIRED"/> 

</XSD:ELEMENT> 

<XSD: ELEMENT NAME- "RELATION" MINOCCURS="0 " 
MAXOCCURS- " UNBOUNDED " > 
10 <XSD: ATTRIBUTE NAME=" ROLE " TYPE="XSD : STRING" 

USE-"REQUIRED"/> 

<XSD: ATTRIBUTE NAME="ID" TYPE="XSD : ID" USE="REQUIRED " /> 
<XSD: ATTRIBUTE NAME="TYPE" TYPE="XSD : STRING" 
USE="REQUIRED"/> 
15 </XSD:ELEMENT> 

<XSD: ATTRIBUTE NAME— " NAME " TYPE="XSD : STRING" 
USE="REQUIRED"/> 

<XSD: ATTRIBUTE NAME=" TEMP LATE" TYPE="XSD : STRING" 
USE="REQUIRED"/> 
20 </XSD:ELEMENT> 
</XSD:SCHEMA> 

The following exemplary definition template illustrates the definition of sub- 
classes for the classes of elements KEYWORD and RELATION, thereby 
25 extending the definitions provided by the above-listed exemplary base schema. 

<TEMPLATE NAME= "ASSET-DEFINITION-TEMPLATE" PARENT= "AS SET- 
SCHEMA. XSD"> 

<DEFINE-KEYWORD NAME=" CATEGORY" TYPE="STRING"> 
30 <ADD- VALUE VALUE=" FINANCE " /> 

<ADD- VALUE VALUE=" BANKING" /> 
</DEFINE-KEYWORD> 

< DEFINE— KEYWORD NAME=" PRICE" TYPE=" DECIMAL " /> 
<DEFINE-KEYWORD NAME="ALIAS " TYPE^" STRING" /> 
35 <DEFINE-RELATION ROLE="USES" TYPE="ASSOCIATION" /> 

< DEFINE -RELATION ROLE=" PREDECESSOR" TYPE—" PREVIOUS-VERSION"> 

<MAX-OCCURS VALUE="l"/> 
</DEFINE-RELATION> 
</TEMPLATE> 
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The above-illustrated exemplary definition template makes use of elements 
DEFINE-KEYWORD and DEFINE-RELATION to define specific sub-classes for 
these respective classes of elements defined by the exemplary base schema. More 
5 specifically, for class KEYWORD, the exemplary definition template defines a 
sub-class CATEGORY having two possible values: FINANCE and BANKING. 
The exemplary definition template defines two additional sub-classes for the class 
KEYWORD including PRICE and ALIAS. For the class RELATION, the 
definition template defines two sub-classes of USES and PREDECESSOR. 
1 o The following exemplary constraint template provides requirements for the 

use of, and constraints for, the instances of the elements. 



<T EM PLATE NAME=" ASSET-CONSTRAINT-TEMPLATE" PARENT="AS SET- 
DEFINITION-TEMPLATE . XML"> 
15 <USE-KEYWORD NAME= " CATEGORY" /> 

<USE-KEYWORD NAME=" PRICE "> 
<MAX-OCCURS VALUE="l"/> 
</USE-KEYWORD> 

<USE-RELATION ROLE=" PREDECESSOR" /> 
20 <USE-RELATION ROLE="USES"> 

<MIN-OCCURS VALUE="l"/> 
</USE-RELATION> 
</TEMPLATE> 



25 The above-illustrated exemplary constraint template makes use of elements USE- 
KEYWORD and USE-RELATION to define specific requirements for instances 
for the sub-classes of elements defined by the definition template. More 
specifically, the exemplary constraint template 10 allows at least one instance of an 
element belonging to the sub-class CATEGORY. The exemplary constraint 

30 template further allows at most one instance of an element belonging to the sub- 
class PRICE. Similarly, the exemplary constraint template allows at least one 
instance of an element belonging to the sub-class PREDECESSOR, and requires at 
least one instance of an element belonging to the sub-class USES. 
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The following pseudocode illustrates an exemplary document that describes 
a reusable software asset, and which complies with the exemplary base schema, 
definition template, and constraint template listed above. 

<ASSET NAME=" BANKING -AS SET -2 . 0" TEMPLATE=" ASSET-CONSTRAINT- 
TEMPLATE . XML"> 

< KEYWORD NAME=" CATEGORY" VALUE=" BANKING" /> 

< KEYWORD NAME=" PRICE" VALUE="100 . 0 0" /> 

< RELATION ROLE="USES" I D=" CURRENCY -AS SET -4 . 1 " 
TYPE="ASSOCIATION"/> 

< RELATION ROLE=" PREDECESSOR" I D=" BANKING-ASSET- 1 . 0" 
T YPE= " PREVIOUS- VERS ION " /> 
</ASSET> 

The form of asset capture module 26 may vary depending on whether asset 
management system 6 is configured for manual, semi-automated, or automated 
asset capture. Asset capture module 26 may comprise, for example, editing tools by 
which a user 39 can manually supply information to complete or augment the 
information captured from repository 4A. In addition, the user may interact with 
the editing tools to resolve any conflicts between the extracted asset information 
and the required information. For semi-automated or automated environments, 
asset capture module 26 may invoke one or more scripts to automate the 
augmentation of information with the asset information extracted by asset source 
20. Asset capture module 26 may be embedded within asset management system 6 
as illustrated, or remotely connected to the asset management system 6. 

In some fully automated environments, asset source 12Amay bypass asset 
capture module 26 by withholding notification 28, and may issue notification 32 to 
publishing module 24 indicating that the asset is ready for publishing to asset 
library 36. In fully automated environments, asset source 12A validates the asset 
information using asset definition templates 47. 

Upon receiving notification 32, publishing module 24 issues messages 34 
to asset source 12A to retrieve the normalized asset from asset source 12A. Upon 
retrieving the normalized asset, publishing module 24 stores the asset within asset 
library 36. 
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Asset management system 6 may further include a modeling module 38 
that allows users 8 to develop models 37 that represent functionality of interest to 
the enterprise. For example, user 8 may interact with modeling module 38 to 
develop models 37 that may include process models, structural models, resource 
models, implementation models, and the like, for a software development project. 
Modeling module 38 may comprise an integrated proprietary modeling tool, or any 
conventional modeling tool capable of producing modeling information, such as 
Rational Rose™ from the Rational Software Corporation of Cupertino, California, 
or combinations of both such tools.. 

Asset retrieval module 42 allows users 8 to access and manage asset data 
within asset library 36. In particular, asset retrieval module 42 allows one or more 
users 8 to develop model-driven search specifications (search specs) 48. In other 
words, asset retrieval module 42 allows users 8 to select elements from one or 
more of models 37 to build search specifications 48. Scoring engine 44 scores 
each asset published by publishing module 24 against search specifications 48 to 
aid in identifying the most relevant assets within asset library 36. In this manner, 
users 8 can selectively retrieve assets from asset library 36 using modeling data 
from models 37 to guide the search process. Asset library 36 may be implemented 
as any data source, such as a relational database management system (RDBMS), an 
object-oriented database, flat files, and the like. 

Library administration (admin) module 46 provides an interface by which 
library administrator 49 can manage asset library 36. For example, library 
administrator 49 may define rules that control the development of search 
specifications 48. In addition, library administrator 49 may edit asset templates 47 
to define new asset types or update the schemas for existing asset types. 

FIG 3 is a block diagram illustrating an example embodiment of asset 
source 12 A. Extraction and validation (EV) module 56 provides the core logic of 
asset source 12A, and may include one or more software components. EV module 
56 periodically accesses repository 4A, or receives notifications from repository 
4A, to identify any new or updated artifacts. Upon identifying any such artifact, 
EV module 56 generates an asset having metadata and data that may include or 
reference the new or updated artifact. EV module 56 caches an instance of the 
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asset within staging area 58. EV module 56 validates the asset using asset 
templates 47 to identify whether the asset is ready for publishing, or perhaps 
requires reconciliation or further artifact data. 

More specifically, EV module 56 generates the assets in a form compliant 
5 with a data description language, and may include metadata as well as actual 

artifact data, or references to artifacts stored within either repository 4A or artifact 
storage 60. Asset source 12A manages artifact storage 60 to store artifact data 
retrieved from repository 4A as needed, and provides artifact interface 53 for 
external access. Accordingly, upon publication to asset library 36 (FIG 2), the 

10 stored assets may comprise metadata, artifact data, references to artifact data 
within artifact storage 60 of one or more asset sources 12 or a central artifact 
storage, or any combination thereof. 

Asset source 12A includes a read-only interface 54 for use by publishing 
module 24 (FIG 2) for extracting assets in a normalized form compliant with a 

1 5 data description language. In other words, publishing module 24 invokes read- 
only interface 54 to direct EV module 56 extract one or more asset from staging 
area 58. Upon receiving the assets from staging area 58 via read-only interface 54, 
publishing module 24 stores the assets within asset library 36. 

In addition, asset source 12A may include a writable interface 52 that 

20 allows asset capture module 26 to augment the artifact information of the 

underlying repository 4A or artifact storage 60. Asset capture module 26 invokes 
read-only interface 54 to direct EV module 56 to extract one or more asset from 
staging area 58. Upon receiving the assets from staging area 58 via writable 
interface 52, asset capture module 26 augments the artifact data via writable- 

25 interface 52 using manual, semi-automated, or automated techniques, as described 
herein. 

The following code illustrates exemplary embodiments for interfaces 52, 
53, and 54, that maybe provided by asset source 50. 

30 /***** Artifact Repository Interface *****/ 

interface Artif actRepository { 

/* Get the installation unique ID of this Artif actRepository */ 
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public abstract String getld() ; 

/* Retrieve the specified artifact from the repository. */ 
Artifact Stream getArtif act ( String assetld, String artif actld) ; 
5 } 

/***** Writable Interface for Artifact Repositiory *****/ 
interface WriteableArt if act Repository extends Artif actRepository { 

10 /* Store the given artifact in the repository */ 

void storeArtif act (String assetld, String artif actld) ; 

/** Remove the specified artifact from the repository */ 
void removeArtif act (String assetld, String artifactld); 
15 } 

/***** Read-only Interface for Asset Source *****/ 
interface AssetSource extends AssetRepository { 

/* Get the installation unique ID of this AssetSource */ 
20 public abstract String getld() ; 

/* Get the XML representation of the specified asset. */ 
public abstract String get Asset (String assetld); 

25 /* Get all publish-ready assets available from this AssetSource. 

Returns a collection of Strings that are the XML representation of 
the assets */ 

public abstract Collection getAssetsO; 

30 /* This method is used as a callback from the x% consumer" of this 

AssetSource, such as the publishing module, to indicate that it 
is now using the asset and that the AssetSource should not allow 
changes to the visble artifacts of the asset. */ 
public abstract void publishAs set (String assetld); 

35 

/* This method may be used to give the AssetSource an XML 
structure consisting of a list of classifier criteria which is 
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then used by the AssetSource to expose only those assets from its 

underlying sources that meet the given criteria. * / 

public abstract void setFil ter (String classif icationCriteria) 

5 /* Register the given consumer, such as the asset capture module 
or the publishing module, for notification of new assets or 
changes to existing assets. */ 

public abstract void registerConsumer (As set Sour ceConsumer 
consumer) ; 
10 } 

/***** writeable Interface for Asset Source *****/ 
interface Wr iteableAssetSource extends AssetSource, 
Wr i t e ab 1 e Ar t i f ac t Rep o s i t ory { 

15 

/* Create a new asset into the asset source (used by the asset 
capture module to create new assets either from scratch or from 
existing XML asset documents. */ 

public abstract void createAsset (String assetXMLDoc) ; 

20 

/** update an existing Asset in the repository. */ 
public abstract void updateAsset (String assetXMLDoc) ; 

/* Remove an Asset from the repository */ 
25 public abstract void removeAsset (String assetld) ; 
} 

FIG. 4 is a flowchart illustrating in further detail the interactions between 
an example asset management system 6 (FIG. 1) and asset sources 12 to facilitate 
the reuse of assets within an enterprise. Initially, publishing module 24 (FIG 2) 

30 and asset capture module 26 of asset management system 6 register with each of 
asset sources 12 as potential "consumers" of assets (68). During the registration, 
each of publishing module 24 and asset capture module 26 may communicate a 
unique communication handle, such as a port number, socket handle, callback 
pointer, and the like, which asset sources 12 use of to communicate with the 

35 modules. In particular, asset sources 12 may use the communication handles to 

notify publishing module 24 and asset capture module 26 of new or updated assets. 
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When asset sources 12 detect new or updated artifacts within repositories 4 
(70), the asset sources 12 extract the information from repositories 4 (72). Asset 
source 12 A, for example, may extract new or updated artifact information stored 
within repository 4A. For exemplary purposes, the remainder of FIG 4 is 
5 described in reference to asset source 12A and repository 4A. 

After extracting the artifact information, asset source 12 A, generates the ■ 
asset based on the extracted artifact information in a form that complies with a data 
description language, such as XML, and stores the asset within staging area 58 
(74). Asset source 12A selects one or more asset templates 47 that provide an asset 

10 schema for controlling the generation. During this process, asset source 12A 

validates the generated asset to determine whether any additional information is 
needed to augment or reconcile the artifact information (76). 

If, based on the validation, additional information is need to augment or 
reconcile the artifact information, asset source 12A determines whether the asset is 

15 an editable asset, possibly based on configuration information or the asset schema 
provided by asset templates 47 (78). If so, asset source 12A sets a status of the 
asset as "editable" (80), and issues notification 28 to asset capture module 26 to 
indicate that an editable asset is available within staging area 58 (82). 

In response, asset capture module 26 provides the required information, 

20 possibly in a manual, semi-automated, or fully-automated maimer (84). In 

addition, asset capture module 26 may assist users 8 in reconciling the instance of 
the asset stored within staging area 58 with a current version of the asset that may 
be stored within asset library 36. Upon completion of the editing process by asset 
capture module 26, asset source 12A changes the status of the asset within staging 

25 area 58 from "editable" to "publishable 55 (86). Similarly, if the asset was non- 
editable, or if additional information was not needed (no branch of 78), asset 
source 12A bypasses asset capture module 26 and marks the asset as ''publishable" 
(86). 

Next, asset source 12A issues notification 32 to publishing module 24 that 
30 an asset within staging area 58 is ready for publishing (88). Finally, publishing 

module 24 retrieves the asset from asset source 12A (90), and publishes the asset to 
asset library 36, possibly in a manual, semi-automated, or fully-automated manner, 
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thereby making the asset available to users 8 via asset retrieval module 42. Asset 
source 12A sets the status of the asset within the staging area as "published" (90), 
and repeats the process for subsequent new or updated asset artifacts. 

The update and publication process described above need not be triggered 
5 by the detection of new or updated artifact information within a repository. User 8 
may, for example, trigger the process by selecting an asset within asset library 36, 
and initiating an update process (as indicated by dashed line 94). In particular, 
asset capture module 26 may reconcile the instance of the asset generated by asset 
module 12A with a current version of the asset stored within asset library 36. User 
10 8 may also initiate the creation of a new asset through this process by selecting one 
or more template(s) and proceed edit the newly created asset according to the 
templates. 

FIG. 5 is a block diagram illustrating exemplary an asset source hierarchy 
100 in which asset sources 102A-102E (herein asset sources 102) are coupled to 

15 repositories 104A-D. As illustrated, asset sources 102 need not have a one-to-one 
relationship with repositories 104, and may be hierarchically arranged to provide 
multiple abstract levels as assets are captured and published. Hierarchy 100 is 
illustrated for exemplary purposes. Accordingly, asset sources 102 maybe 
hierarchically arranged as required to capture assets from a wide-variety of 

20 environments. 

For example, asset sources 102A-102C are coupled to repositories 104, and 
form a first layer of asset source hierarchy 100. More specifically, asset source 
102 A is configured to generate assets based on artifacts stored within repository 
104A. Similarly, asset source 102B is configured to generate assets based on 

25 artifacts stored within repository 104B. Asset source 102C is configured to 

generate assets based on artifacts stored within repository 104C and repository 
104D. In other words, asset source 102C monitors both repository 104C and 
repository 104D, and generates assets based on new or updated artifacts. 

In the illustrated example hierarchy 100, asset sources 102A-102C 

30 comprise read-only asset sources, and publish assets to upper levels of asset source 
hierarchy 100 without invoking a capture tool. Accordingly, asset sources 102A- 
102C need not support writeable interfaces. 
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Asset source 102D receives arid aggregates assets from asset sources 102 A, 
102B. In particular, asset source 102D may receive incomplete assets from asset 
sources 102 A, 102B 5 and may combine the artifacts, or references thereto, of the 
received assets to form aggregate assets. Asset source 102D may invoke asset 
5 capture tool 106 A to augment or reconcile the aggregate assets. 

Similarly, asset source 102E receives and aggregates assets from asset 
sources 102C, 102D, and may invoke asset capture tool 106B to augment or 
reconcile the aggregate assets. Accordingly, the aggregate assets produced by 
asset source 102E should be complete, and in a state for publishing to asset library 
10 36. Alternatively, asset sources 102D, 102E, for example, may treat assets from 
each of sources 102A, 102B, 102C as independent assets for publishing to asset 
library 36. 

FIG. 6 is a block diagram illustrating in further detail one embodiment of 
asset capture module 26 of asset management system 6. For manual or semi- 

1 5 automated generation of assets, users 8 interact with user interface 1 10 to provide 
additional asset information, or reconcile the current artifacts captured by asset 
source 12A from repository 4 A. Capture logic 112 drives user interface 1 10 to 
interact with users 8 according to asset schemas defined by asset templates 47. In 
this manner, asset capture module 26 offers users 8 and library administrator 48 

20 (FIG. 2) the flexibility of changing asset capture workflow, as well as the structure 
and content of the captured assets, by change asset templates 47. 

During the process, capture logic 1 12 maps the artifacts of the asset 
produced by asset source 12A to searchable elements of models 37. In particular, 
capture logic 112 makes use of rules engine 120 to map the metadata and artifact 

25 data of the generated assets to elements of models 37. During the asset generation 
process, capture logic 112 allows users 8 or a library administrator 48 (FIG. 2) to 
dynamically define and modify mapping rules 1 1 8 to customize the mapping 
process. In one embodiment, rules engine 120 may comprise a Java-based rules 
engine, such as JRules™ from ILOG Incorporated of Paris, France. Other 

30 embodiments may implement the mapping process through other techniques, e.g., 
hardcoded procedural logic. 
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FIG. 7 is a flowchart further illustrating an example mode of operation of 
asset capture module 26. Initially, capture logic 112 receives notification 28 from 
asset source 12A indicating an asset within staging area 58 has been generated and 
is ready for editing (122). In response, capture logic 1 12 retrieves the current asset 
from asset source 12A (124), and augments or reconciles the artifacts of the current 
asset (126). Based on asset templates 47, as described above, capture logic 1 12 
may drive user interface 1 10 to capture the required information from users 8. 
Alternatively, capture logic 112 may invoke one or more scripts or other 
components to automate the process. 

Next, capture logic 112 maps the asset to one or more model elements of 
models 37 (128). Capture logic 112 may, for example, invoke rules engine 120 to 
perform the mapping based on mapping rules 118. In addition, capture logic 1 12 
may drive user interface 1 10 to map the assets to model elements based on input 
from users 8. In this manner, capture logic 112 builds associations between 
generated assets and the elements of models 37. Assets may be associated with, 
for example, interfaces, components, functions, case steps, and other elements that 
may be described within models 37. 

Next, capture logic 112 updates the asset to include additional metadata 
based on the developed mapping, as well as any additional artifacts and other 
metadata that may have been provided by users 8 or automated scripts. (130). 
Finally, capture logic 112 communicates the updated asset to asset source 12A for 
storage in staging area 58 (132). 

FIG. 8 is a flowchart illustrating an example operation of retrieving 
reusable assets from asset management system 6. In response to input from one of 
users 8, asset retrieval module 42 selects one or more elements of models 37 (140) 
and constructs a model-based search specification 48 (142). The user may, for 
example, graphically view one or more of models 37, and identify elements, such 
as interfaces, components, functions, case steps, and the like, for inclusion within 
the search specification. In addition, asset retrieval module 42 may receive 
additional search criteria, such as keywords and other classifiers including an 
operating system, license type or language, for inclusion within the search 
specification 48 (144). 
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Next, asset retrieval module 42 directs scoring engine 44 to search asset 
library 36 in accordance with the search specification 48 (146). Based on the 
search specification, scoring engine 44 ranks the assets within asset library 36 
using a scoring algorithm that determines, for example, how closely each asset 
5 satisfies the criteria of the search specification 48 (148). 

Asset retrieval module 42 displays to the user the ranked assets found 
within asset library 36 by scoring engine 44 (150), and selects one or more of the 
assets in response to user input (1 52). Based on user request, asset retrieval 
module 42 attaches the selected assets to the search specification 48 (154). In this 
1 0 fashion, the user can selectively retain the assets for a software project. In one 

embodiment, scoring engine adaptively updates the search specification 48 based 
on the assets attached by the user, thereby dynamically refining scoring algorithm 
(156). 

Domain Reference Model 

15 The asset capture and identification tools of the invention allow resources 

to be mapped to a domain reference model (DRM). The DRM may be built in 
commercially available standalone software, such as Rational Rose, available from 
Rational Software of Lexington, Massachusetts, or may be directly integrated as a 
part of a standalone tool. 

20 A DRM identifies both atomic and higher-level tasks or process elements. 

Preferably, these elements are organized in two different models. The first model 
is the structural model, which is similar in organization to a library of code 
components. Each reference component in the structural model contains one or 
more functions applicable to the domain. These functions may be organized in 

25 intermediate groupings called interfaces that associate functions according to 

expect usage patterns or other criteria. However, the components defined in the 
structural model are not actually implemented as executable code, but simply serve 
as a reference model of possible functions within the domain. 

The second model is generally a business process model, which identifies 

30 higher-level areas within the domain and breaks them into processes and 

subprocesses. At the atomic level, the processes are broken down to "use cases," 
which detail the necessary steps of a particular task. These steps are associated 
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with the components, interfaces, and functions in the structural model, and may be 
repeated in different combinations in the various use cases. The model need not be 
organized around a business structure, but may comprise any appropriate topical 
organization (e.g., a technical reference architecture for software component 
5 implementation and deployment). 

The business-process side of a DRM for the insurance industry is shown in 
FIGS. 9-12. FIG. 9 shows a top-level categorization of life insurance processes, 
organized into the categories Underwriting, Illustrations, Billing/Collections, Party 
Changes, Policy Changes, Disbursements, Claims, Remediation, Taxation, and 

10 Accounting. As shown, Remediation has been selected, and subcategories of 

remediation processes are shown at right, including Customer Inquiry Handling, 
Insurance Commissioner Inquiry Handling, Scoring a Complaint, Determining a 
Settlement Type, and Processing Settlement. As shown in FIG. 10, if Processing 
Settlement is selected, additional subtopics No Settlement Amount, Cash Surrender 

15 without Surrender Charge, Return of Premiums Paid, Return of Premiums Paid 
Less Insurance Costs, and Policy Cancellation/Restore Original Policies. As 
indicated by icon 210, Cash Surrender without Surrender Charge is a lowest-level 
process, which has an associated set of use cases. Cross-branching may also be 
allowed, wherein certain subprocesses appear in more than one process. 

20 The set of use cases represent a series of steps making up an algorithm for 

executing the associated subprocess. For the Cash Surrender without Surrender 
Charge, a portion of the associated set of use cases is shown in graphical form in 
FIG. 1 1 . The use case diagram may indicate responsible personnel (settlement 
clerk 212) as well as individual use cases (the algorithm steps). 

25 FIG. 12 shows a portion of the structural form of the functions associated 

with the use case "Determine Federal Withholding Amount." The reference 
component Determine Federal Withholding Amount 214 includes five functions 
216 grouped into one interface that may be performed (e.g., by subroutines) in 
connection with determination of federal withholding: 

30 ComparePolicyRegTINtoSettlementTINO, DetermineResidenceAddressCountry() ? 
DetermineRequiredFWAmount(), CalculatePolicyOwnerWHAmount(), and 
CompareElectedWHAmounttoRequiredWHAmountO. hi addition, three Policy 
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Record Functions, also grouped into a single interface, are required for this use 
case: GetTIN(), GetResidenceAddressO, and GetNRAStatus(). Some of the 
functions may be specific to the use case and appear only in that case (e.g., 
DetermineRequiredFWAmount()) ? while others are generic and appear in a number 
5 of cases (e.g., GetResidenceAddress()). In addition, expected variable types (e.g., 
a CurrencyValue type that includes both a decimal amount and a string currency 
identifier) may also be specified in the model. 

Asset Capture Tool 

The asset capture module 26 illustrated in FIG 2, referred to below as the 

1 0 asset capture tool, is used to catalogue resources by constructing a metadata 

document for placement into an asset library ('"publishing" the asset). Individual 
data types and functions from the asset are mapped to the domain reference model 
(or to multiple models), and the mappings are saved as metadata for later searching 
to identify usable assets for new projects. In preferred embodiments of the 

15 invention, additional information may be included such as comments on the quality 
of the mapping, details of the asset characteristics such as language and licensing 
arrangements, or structural diagrams of the asset. 

The asset capture process according to one embodiment of the invention is 
illustrated in FIGS 13-25. The menu 240 shows the steps of the workflow process. 

20 Log 242 creates a running record of asset acquisition. The log window preferably 
remains throughout the asset capture process, but has been omitted from 
subsequent figures in order to conserve space. 

Initially, the user configures the asset capture tool, setting options for the 
acquisition process such as the level of detail to be saved in the log, the group of 

25 DRMs to be used in the mapping process, and the schema and target repository for 
storing information. 

The user then proceeds to the definition stage. The asset to be added to the 
library is located, and general information about the asset is entered in the 
overview section. FIG. 13 shows the classification step. Using the data entry box 

30 244, the user specifies values for descriptors relating to the asset as a whole. In the 
embodiment shown, required descriptors are marked with an asterisk; a value for 
these descriptors must be entered before the user can proceed with publication of 
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the asset. The descriptors shown in FIG. 13 represent nonlimiting examples of the 
types of information that may be stored about the asset. A standard set of 
descriptors is preferably provided as part of the schema set in the configuration 
step, which may include any information relevant to a person deciding whether to 
5 use the asset, including descriptions of the asset itself and associated information 
such as licensing options. The user may also add one or more additional 
descriptors at this stage. These descriptors will not be added to the schema for 
other assets, but will be included in the metadata pertaining to the asset being 
added to the database. 

10 Once the classification step has been completed, the user specifies the asset 

model and component diagram that will be used to catalogue the asset. If an asset 
model and/or a component diagram do not yet exist, the asset capture tool will 
preferably give the user the option to create them, as shown in FIG. 14. 

As part of the asset capture process, a component interface diagram will be 

15 created for the asset (unless one already exists). Preferably, the asset capture tool 
will be able to create or update the component diagram either automatically or 
manually, and will offer the user a choice of either procedure, as shown in FIG. 15. 
However, systems that provide only manual or only automatic means for building 
the component diagram also fall within the scope of the invention. The following 

20 description pertains primarily to automatic methods of generating the component 
diagram. However, any "manual" method that produces a component interface 
diagram compatible with the asset capture tool (preferably conforming to the 
Unified Modeling Language standard) is considered to be within the scope of the 
invention. 

25 To automatically generate the component interface diagram, the asset 

capture tool first identifies functions within the asset, and preferably allows the 
user to specify which functions are external, as shown in FIG. 16. The asset shown 
includes a collection of functions used for management of different currencies (for 
example, functions for determining exchange rates). Checkboxes 246 are used to 

30 identify functions that are intended to be accessible to a developer using the 
resource, e.g., functions and data types that are part of the API for the asset. 
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Preferably, the user can view asset documentation for the functions, for example 
via a Show Details button 248. 

As shown in FIG. 17, the asset capture tool next identifies any custom data 
types used by the external functions of the asset, and allows the user to select any 
5 additional data types that are part of the API for the asset. (Standard "primitive" 
data types such as integers and Boolean variables are preferably not presented at 
this stage, although they are taken into account in later steps of the asset capture 
process). Again, details on the data types may be viewed, and the structural model 
may be adjusted, via buttons 250. For example, a collection of primitive data types 

10 making up a compound type may be viewed (e.g., a CurrencyValue type that 
includes both a decimal amount and a string identifying the currency). 

The data on external functions and data types is used to generate an 
interface diagram, typically using an external tool such as Rational Rose. A 
generated interface diagram for the currency management asset is shown in FIG. 

15 18. The diagram shows the selected external interfaces 252 presented by the 

CurrencyManagement component. Additional information about the functions 
may be accessed through the illustrated graphical user interface (GUI). After 
reviewing the diagram, the user is preferably given the option to "publish" the 
diagram. In one embodiment of the invention, the diagram is saved as an HTML 

20 document, which is added to the metadata for the asset. The HTML document is 
available to a later user who finds the asset in the database, so that he can better 
evaluate its suitability for the task at hand, even if he does not have Rational Rose 
or a similar external tool installed on his machine. 

In the final step of the asset definition phase, other descriptive elements of 

25 the asset (referred to herein as "artifacts" of the asset) such as its architectural 

assumptions, examples, warranty, and reviews may be specified, as shown in FIG. 
19. Preferably these artifacts may be specified by value (where a copy of the 
artifact is made for later publication as part of the asset into the asset library), by 
reference (where a URL or other form of file reference is documented as part of the 

30 asset), or by description (where a text field documents the (typically physical) 

location of the artifact). Artifacts may include both functional and nonfunctional 
characteristics of the asset. Nonfunctional characteristics are distinct from the 
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functional characteristics that are mapped against the DRM. In preferred 
embodiments, both nonfunctional and functional characteristics can be searched. 

After the asset definition phase has been completed, synonyms for the asset 
may be defined, as shown in FIG. 20. These synonyms are designed to improve 
5 the quality of searches by associating words used in the asset functions and 
descriptions with likely synonymous search words. For example, if an asset 
routinely uses "schedule" internally to refer to a collection of insurance rates, it 
may be desirable to associate "schedule" with "rates" to improve the probability of 
appropriate functions being displayed during a search for functions handling 

10 insurance rates. As will be described in more detail in connection with searches, 
one system according to the invention uses substring substitution of synonyms to 
improve search quality. More complicated semantic analysis in view of defined 
synonyms may also be used and falls within the scope of the invention. 

After definition of asset-specific synonyms, the user maps the asset to one 

15 or more DRMs contained within the group of models selected during the 

configuration step. The reference model is selected, as shown in FIG. 21. In the 
embodiment shown, only one reference model may be selected, but multiple 
portions of that model may be run simultaneously. In other embodiments, multiple 
DRMs may be selected to run either simultaneously or sequentially, hi FIG. 21 , 

20 the Currency Management model includes both management functions and 
exchange functions. If the user knows that only management functions are 
performed by the asset, he may select only that portion of the model for mapping. 
If both management and exchange functions are performed, or if the user is not 
certain of the full scope of functions performed, all parts of the model may be used. 

25 The user may view synonyms that have been defined for the DRM or on an 

enterprise-wide basis, as shown in FIG. 22. In the embodiment shown, the user 
cannot add synonyms to the DRM or to the library as a whole, but has the option to 
.enable or disable certain synonyms. This feature is particularly useful for words 
that may have multiple meanings. For example, "money" is enabled as a synonym 

30 for "currency." However, if the user knows that the asset uses the term "schedule" 
to mean a collection of insurance rates, he may wish to disable the synonym of 
"time" for "schedule." 
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Once the reference model and synonyms have been selected, the asset can 
be mapped against the DRM. In preferred embodiments, the mapping begins with 
data types and proceeds through functions, working from the least to the most 
complex. By using information from earlier mappings, the quality of automatic 
5 suggestions for mapping can be improved. 

FIG. 23 shows the first step in mapping data types. The custom data type 
CurrencyValue exists in the asset, as shown in left panel 254. When 
CurrencyValue is selected, the reference model is searched, using substring 
substitution for known synonyms, and one or more suggested model datatypes are 

10 displayed in right panel 256. hi order to select the best match, details for either the 
asset datatype or the model datatype can be accessed via the Details buttons 258. 

FIG. 24 shows the system after a suggested datatype has been selected. 
Four descriptors have been provided to describe the quality of the mapping. 
Boolean types additional-data and partial-data allow the user to specify whether the 

15 asset datatype contains more or less information than the model datatype. In 

addition, the quality of the matching can be stored in the affinity field, and a notes 
field allows the user to describe any special characteristics of the mapping. Once 
the user has entered values for these descriptors and clicks the Map button 260, the 
mapping for CurrencyValue is added to the metadata for the asset, as shown in 

20 FIG. 25. This mapping is then used to refine the quality of suggested mappings for 
later (generally more complex) datatypes and for functions. 

The mapping process for functions proceeds in the same fashion as the 
mapping process for custom datatypes. The user has available the same set of 
descriptors for describing the quality of the mapping between available external 

25 functions that were available for mapping datatypes. By mapping datatypes first, 
the asset capture tool can use datatype equivalencies to select likely candidates for 
functional equivalencies. For example, a function called Convert() that takes 
CurrencyValue as an argument may be a more likely match in a currency exchange 
package than one that takes GregorianDate. Functions, like datatypes, may be 

30 mapped in a many-to-many relation, and the additional-data, partial-data, and 
comments fields can be used to annotate the quality and characteristics of the 
mapping(s). 
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Once all functions and datatypes have been mapped to the DRM to create 
the component diagram, the accumulated metadata for the asset can be uploaded to 
the database for searching. Any of a number of standard file formats may be used 
for database entries. 

5 Model Based Search Specification 

Once assets have been classified in a library database, a search engine 
should be provided to allow them to be accessed. While standard search engines 
may be used on the database described above, it is preferable to use a specialized 
engine designed to take maximum advantage of the unique data stored in the 
10 library. 

According to one embodiment of the invention, the search engine is 
designed to allow construction of a search specification using either the process- 
based side or the structural side of a domain reference model as described above. 
FIGS. 9-12 and 26-30 show the process of constructing a search specification, 

15 performing a search, and interpreting the results. 

A user unfamiliar with software development can nevertheless identify 
assets useful for creating a tool to solve a particular need, by navigating the 
business process-based side of the domain reference model shown in FIGS. 9-12. 
Proceeding through FIGS. 9 and 10 as described above, the user selects functions 

20 from within the DRM until he reaches a use case diagram. The use cases making 
up the diagram can be viewed as shown in FIG. 1 1 . For any use case within the 
diagram, the user may view associated functions from the structural portion of the 
DRM, as shown in FIG. 12. The user then selects the desired functions from the 
list for addition to the search specification. Preferably, the user may be given the 

25 option to automatically select all of the functions associated with the use case, or 
selected blocks of functions associated with individual use case steps. The 
graphical user interface and drill-down through the process side of the DRM makes 
it easy for the user to identify all of the needed functionality, even if he is 
unfamiliar with the conventional process of developing technical specifications. In 

30 a preferred embodiment of the invention, the library database also provides a DRM 
search facility that allows users to selectively enter a DRM at any point based on 
query results (e.g., a, keyword search for DRM elements associated with the term 
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A search specification constructed in this manner is shown in FIG. 26. 
Two functions 280 have been identified from the candidates shown in FIG. 12: 
GetNRAStatus from the PolicyRecordManagement functions, and 
addExchangeRate from the CurrencyManagement functions. In addition, the user 
5 can specify general parameters 282 and function-specific parameters 284 for how 
close a match is required. 

Keyword searches may also be available through the search engine, as 
shown in FIG. 27. Particularly in these searches, the search engine preferably 
makes use of the asset-specific, DRM-specific and enterprise- wide synonyms that 
10 were defined during initial library configuration and during asset capture. Thus, 
when a user searches for "currency," the system returns both assets with functions 
and datatypes involving "currency" and functions and datatypes involving 
"money." 

In either type of search, the user preferably may specify nonfunctional 
15 requirements such as operating system, license type, or language. These 

requirements may preferably be given weights in the same manner that individual 
functions can be weighted. 

A result for the search specification shown in FIG. 26 is shown in FIG. 28. 
Three potentially useful assets have been identified; they are ranked according to 
20 how closely they fit the search criteria. The user may select some or all of the 

assets returned for further investigation via checkboxes 285. The selected assets 
are then attached to the search specification, as shown in FIG. 29. The search 
engine preferably learns by observing which assets are attached, in order to refine 
its scoring algorithm for later searches; those resources that were attached to the 
25 search specification will be preferentially returned in subsequent similar searches. 

Before or after the assets have been attached to the search specification, the 
user can investigate them in more detail, as shown in FIG. 30. The Asset Details 
window allows the user to view any of the descriptors that were entered during the 
asset capture process, such as reviews of the asset and support issues. The user can 
30 use the detailed data to select the assets he wishes to acquire. 

One feature of the invention is that a user who is familiar with business 
processes, but not with construction of formal technical specifications, can build a 
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One feature of the invention is that a user who is familiar with business 
processes, but not with construction of formal technical specifications, can build a 
search specification and attach useful assets to it. The search specification can be 
used by others who are less familiar with the business process, but who are familiar 
5 with software development, to identify assets that can be readily used together. By 
allowing such collaboration, the invention provides more effective leveraging of 
software assets within an enterprise. 

In the event that a search specification results in no potentially useful assets 
being found, the user preferably may specify that the specification be published as 
10 an initial requirements document for new asset development. If a partial match is 
found, the user preferably may similarly publish the unmatched portion of the 
specification as a requirements document. The user may also choose to mark a 
search specification such that the user will be informed in the event that any asset 
subsequently published into the library sufficiently conforms to the specification. 

15 Asset Management 

In preferred embodiments of the invention, the system also facilitates the 
software asset acquisition process. An acquisition workflow is shown in FIG. 3 1 . 
Once an appropriate asset or assets have been identified using the search 
specification, the user may submit an acquisition request 302. Acquisition requests 

20 are associated with individual development projects. 

The system first determines whether the asset is associated with the project 
304. If it is, the system checks to see if the asset is registered 306. If the asset is 
both associated with the project and registered, then it is already available for use 
in development and its status is displayed to the user 308. If the asset is associated 

25 with the project and not registered, it may be that it is already under consideration 
by the Project Manager, or that it has previously been rejected. If the system 
determines that the asset has not been rejected 3 10, it displays the asset's 
"pending" status to the user 308. If the asset has previously been rejected, then the 
user is required either to give a reason for requesting reconsideration of the 

30 rejection 3 1 2 or to cancel the request. 

If the asset is not already associated with the project, or if the user is 
requesting reconsideration of a rejection, the asset status is set to "pending project 
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manager approval," 314 and the Project Manager is notified 3 1 6 of the new 
acquisition request. 

A summary of asset acquisition requests according to one embodiment of 
the invention is shown in FIG. 32. Depending on the needs of the individual 
5 system, this view may be available only to Project Managers and other designated 
users, to all users for a particular project, or to all users in the system. 

Each pending request is preferably listed by requester 318, project 320, and 
name 322. Additional information may also be included such as version numbers 
324, descriptions 326, and notes 328. By selecting links 330, the manager may 

10 view the details of any request. 

FIG. 33 shows a typical request detail screen for an asset, viewable at least 
by a Project Manager for a project that has requested the asset. Preferably, all 
requests for the assets are shown on a single screen, with the reasons for the 
requests listed by the requesters. If the user viewing the request screen is 

15 empowered to acquire software, he may enter license and purchase data via an 
asset acquisition screen as shown in FIG. 34. (Users empowered to acquire 
software may also be able to directly access the asset acquisition screen from a 
search result or by identifying the asset to be acquired manually). 

In some embodiments of the invention, the acquisition screen may allow 

20 the user to send a purchase order, a request for internally developed assets, or 
otherwise formally acquire the asset. Alternatively, the acquisition screen may 
simply memorialize the acquisition of the resource by other channels, as in the 
screen shown in FIG. 34. In that screen, the acquirer may record any software 
license keys, describe the location of hardware keys, and make any necessary notes 

25 on the conditions of the software purchase. If the license is for a certain number of 
instantiations or workstations, there may also be provided a mechanism for 
assigning instantiations or workstations to projects to avoid violating the terms of 
the license. For internally developed or acquired assets, there may be departmental 
cross-charges for use of the asset; these may also be tracked in preferred 

30 embodiments of the invention. 

The system preferably also includes means for tracking the usage of 
individual assets by different projects. In preferred embodiments, this information 
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may either be viewed directly by the library in the form of prebuilt reports or 
exported for further processing. As an example of a prebuilt report, FIG. 35 shows 
a summary of published and unpublished assets created by a particular user or 
department. For published assets, links 334 allow the publisher or another user to 
5 review the projects currently registered to use the asset. For users with the 

appropriate permissions, departmental cross-charges and the like may be modified. 

Various embodiments of the invention have been described. These and 
other embodiments are within the scope of the following claims. 
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CLAIMS: 

1 . A system comprising: 

a capture module to map data types and resource functions to a domain 
model; and 

5 a database to store the data representative of the mapping. 

2. The system of claim 1, wherein the domain model comprises: 
a process model comprising processes and use cases; and 

a structural model comprising reference components, reference interfaces, 
and reference functions. 

10 

3. The system of claim 2, wherein portions of the process model are linked to 
reference components, reference interfaces, or reference functions of the structural 
model. 

4. The system of claim 2, wherein the domain model comprises a plurality of 
15 process models, portions of each process model linked to reference components, 

reference interfaces, or reference functions of the structural model. 

5. The system of claim 2, wherein the capture module allows the user to map 
data types to the structural model. 

6. The system of claim 2, wherein the capture module allows the user to map 
20 functions to the structural model. 

7. The system of claim 1 , wherein the capture module use synonyms to 
suggest mapping candidates. 

8. The system of claim 1 , further comprising a search engine to selectively 
retrieve elements of the model from the database. 

25 9. A method of classifying a resource comprising functions and data types, the 
method comprising: 

receiving a domain model comprising model functions and model data 

types; 
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mapping resource data types to model data types to produce data type 

maps; 

mapping resource functions to model functions to produce function maps; 

and 

storing the data type maps and function maps in a searchable database. 

10. The method of claim 9, wherein the domain model comprises: 
a process model comprising processes and use cases; and 

a structural model comprising reference components, reference interfaces, 
and reference functions. 

1 1 . The method of claim 1 0, wherein portions of the process model are linked 
to reference components, reference interfaces, or reference functions of the 
structural model. 

12. A system comprising: 

a repository to store artifacts; 

an asset source to generate a software asset based on the artifacts; and 
an asset management system to receive the software asset from the asset 
source and to store the software asset within an asset library. 

13. The system of claim 12, wherein the asset source generates the software 
asset to include references to the artifacts within the repository. 

14. The system of claim 12, wherein the asset source generates the software 
asset upon detecting a new or updated artifact within the repository. 

15. The system of claim 12, wherein the asset source generates the software 
asset in a format that complies with a data description language. 

16. The system of claim 15, wherein the data description language comprises 
the extensible markup language (XML). 
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17. The system of claim 12, wherein the asset source comprises a staging area 
to store the software asset prior to storage within the asset library by the asset 
management system. 

5 18. The system of claim 12, further wherein the asset source generates the 
software asset in a normalized format in accordance with an asset template. 

19. The system of claim 18, wherein the asset template defines a schema for 
the software asset in accordance with a data description language. 

10 

, 20. The system of claim 12, wherein the asset source comprises a writable 
interface for editing the software asset. 

21. The system of claim 12, wherein the asset source comprises an artifact 
15 storage to cache artifacts extracted from the repository. 

22. The system of claim 12, further comprising an asset capture tool to update 
the software asset based on additional artifacts. 

20 23. The system of claim 22, wherein the asset capture tool includes a user 
interface to receive the additional artifacts from a user. 

24. The system of claim 22, wherein the asset capture tool includes scripts to 
generate the additional artifacts. 

25 

25. The system of claim 12, further comprising: 

an asset template that defines a schema for a software asset in accordance 
with a data description language; and 

an asset capture tool to update the software asset in accordance with the 
30 asset template, wherein the asset capture tool identifies missing artifacts from the 
software asset based on the asset template. 



39 



WO 03/005243 



PCT/US02/20962 



26. The system of claim 12, further comprising a rules engine to generate 
metadata that maps the software asset to elements of one or more models. 

27. The system of claim 26, further comprising an asset retrieval module to 

5 selectively retrieve the software asset from the asset library based on the metadata. 

28. The system of claim 26, wherein the models comprises at least one of a 
process model, a structural model, a resource model, and an implementation 
model. 

10 

29. The system of claim 12, further comprising an asset retrieval module to 
receive input from a user selecting an element of a model, and to selectively 
retrieve the software asset from the asset library based on the input. 

15 30. The system of claim 29, wherein the asset retrieval module generates a 
search specification based on the user input. 

3 1 . The system of claim 30, further comprising a scoring engine to score the 
software asset within the asset library against the search specification. 

20 

32. The system of claim 12, wherein the artifact comprises one of source code, 
binary code, a requirements specification, a design document, a model, a use case, 
and a collaboration diagram. 

25 33. A system comprising: 

a model having one or more elements; 

a database to store reusable software assets; and 

an asset retrieval module to receive input from a user selecting an element 
of the model, and to selectively retrieve a subset of the software assets from the 
30 database based on the input. 
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34. The system of claim 33, further comprising a rules engine to generate . 
metadata that maps the software assets to the elements the model. 

35. The system of claim 33, wherein the model comprises one of a process 
5 model, a structural model, a resource model, and an implementation model. 

36. The system of claim 33, wherein the asset retrieval module generates a 
search specification based on the user input. 

10 37. The system of claim 36, further comprising a scoring engine to score the 
software assets within database against the search specification. 

38. A method comprising: 

receiving input from a user selecting one or more elements of a model; and 
15 retrieving software assets from an asset library based on the selected 

elements. 

39. A computer-readable medium comprising instructions to cause a processor 
to: 

20 receive input from a user selecting one or more elements of a model; and 

retrieve software assets from an asset library based on the selected 
elements. 

40. A computer-readable medium comprising data structures that store: 
25 software models having elements; and 

software assets having metadata that maps the software asset to the 
elements of the software models. 

30 
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■ , £fe f •: £$St ; Favocfars- , X°^* H*^ 



Search Categories H^v^ ' : j • 



Infof matioin Canter 1 
Support Cittttgf" ^ 7i"1 



TAQS 



- Assist vTaw»- T ■ 



Non-Functional 
R&quir#nfiant S»U 



LogicLtlirarii 



WAP j FEEDBACK j MANAGE MY PROFILE lOGOuT 



• Process ^ased, 
■Navigation" , 



,StrucuraiBased> 
Nayig^tibn 



\ «C0mp Sf>BC»> If • 

j Policy Record Management 



Policy Record Functions 



♦GefllNQ - 
*G et R esidsncsAdd/assQ 
♦GelNRAStatusO 



*. • ■, . «comp spec» > ■ , 
Determine Federal Withholding Ariioi 



6 



DRMQiiery 



214 



Federal Withholding Tax Functions 

♦ComparePolicyRecTINtoSettlementTINO 
♦DetermineResidenceAddressCountryO 
♦OeterrraneR equifBdFWAmountO 
*Calcul at ePol cy 0 wnerWHAmou ntO 
^ompareEtectedWHAmourrtToRequiradWHAMOUMTE) 



>216 
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LogicLibrary Asset Capture Tool 



|; File View ; Help, 



Capture Workflow 



s~Q Asset Capture Workflow 
$ H3 Configuration 



Identification 
Overview 



Classification 



~~S Asset Model 
Solution 
□ Asset Synonyms 
Map 
ihH Export 













X 




X 




X 



Workflow Details 



Q HI Classification (+) 

Hlx|*logiclibrary-descr1ptors (+) 



asset-type 
*applicatlon-programmlng-lnterface 
*executabie-asset 
*iniBllectual-property-type 
*support-level 
*vendor 
author 

originating-project 

creation-level~of-effort 

Intended-domain-general 

intended-domain-specific 

alias 

keyword 



name 




string 


reference 




uriReference 


! |'' ■ < "' : '' \; , h : '^ t '■■ \\ ..' >, >■;"''' ''-,<• ; ;;' ' 1 - , ; \.V ! 
' ( . • ■ v 1 ' .'-■{•' . ,c ^ ;S-,'' ; ' > . '. •, ' . • • * .. i •'■ ' ! . * <• ',i ' ('.:•','• »*••••' f ' - ';• "' 



Back 



> Back 



Next> 



Cancel , 



Log 



*********************************************************** 

** ASSET CAPTURE TOOL LOG 
** version: 1.0 

** log created: fled Jun 27 12:59:39 CDT 2001 

*********************************************************** 
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! File View Help ^ ^^^^S^J 1 - 




; Capture VVorkflow [ j ' , : | 


Workflow Details 'HP PP'p '..v. 'v^ ! \P, ' i Pv' P A 'Pi ',' : '"-PpP PP' ; P; 


0-O Asset Capture Workflow 

da -0 Configuration 

a-S Definition 
j -0 identification 
H3 Overview 
pEI Classification 
E-ED Asset Model 


A Component Diagram is a necessary step in enabling the Asset to be found •! 
through a Model-Based Search Specification (MBSS) in the library, the end » 
result of capturing the Asset Model is a Component Diagram. P ! ! 

iPJease select one of tfefeHoWing: . P . •,; p \ ■ Y ' PpP " j , „',P !; ,{5 ' y v ; . 

j •.. f have a Component Rose;" pp , ' c 
| f have a model butno Cpmportent blag Rose!,, 
r: J do not have a model for the Asset in Rational Rose <JM). 


I^HHH9Q|Mo^el Capture 


[HS Identify Model 
1 HS Diagram Option 
— [3 Solution 
t- □ Asset Synonyms 
ija-Q Map 
• BH8 Export 


>P : <-BacK> : ; ' )• • •; v ; Next > ' :•:] : Pp "» - p [pp. Cancel pj; /.p" P-,, p 


Mg. 14 



WO 03/005243 



15/35 



PCT/US02/20962 



| LogicLibrary Asset Capture Tool ' jjjjlBBW 


File View^Heip : i ' v ; ' : ; : : V V ' : . ,' • / V\"' J'' • .M-:, ;.' ;v ' , : f : • ' y -l ; /; ■;! 


Capture Workflow , 


Worttfow Details •;: ; ; ' ; -/I :y ; ;' ':, • ,\: •[•■•: ■ ■ y< Vv ',"; ,s .; t : '| 


0* □ Asset Capture Workflow 
Configuration 
B~fx| Definition 
[ H3I Identification 
; H5D Overview 
! EI Classification 
a-H Asset Model 
I -^ED Model Capture 
i i H50 identify Model 


JYoU need to provide a Component Diagram for the Asset. You may do this one 
; of the two ways: i ; , ; ; V;! . ' ,'. • ..•;-!/, ' ; ; }U : Z 1 

<^ lAllowtool to crelate/update a Component Diagram ! ' j i ' 

' : 'The (Ifogra^iWbe basetfqn the eternal Data Types and Functions thsii 
. you wW be identifying in the next series of panels.' Please note that , '\ , j 
/additional properties will be added to your model to enable, this process. 

;C Create/updai^a porriponeht Diagram manually { , i ,j ■ ; ! ; 

" ; r.^lihjs. has ; s|eWrjalbenffts\ depending ; on your's'rtoation;' The addition of-" • ' ' 
. LogipLJbrary properties to the model classes and operation will be avoided. 


■■HQ Diaqrarn Option 


( HEI Interfaces 
I f ~~IE] Data Types 
i I Review Diagram 
1 5 L ~0 Publish Model 
j H8 Solution 
L - □ Asset Synonyms 
©-□Map 
{±]-|xl Export 


; |; ^•5Back'i; ( ; :i | r Ne*t> || • •' ■[ 'cy, Cancel. '•!.-. '\ 
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LogicLibrary Asset Capture Tool 



File View : Help 



Capture Workflow 



WorkfloWDefails 



BhQ Asset Capture Workflow 
fe- 0 Configuration 
frS Definition ' 
[ K0 identification 
f Overview ; 
j Classification 



3 Identify Model 
Diagram Option 



i I 

















X 




X 







interfaces 



Data Types 



Publish Model 

I 1 S Solution 

Asset Synonyms 
phO Map 
e-S Export 



Please Ktenttfythe externa! functions of the asset. This can be done by 
utilizing one or both of the following mechanisms !. y ; <; 

1) From the list below, identify the External Functions. 

2) From within Rose, change the Component interface from 
False to True in the LogfcLibraiy tab of the Operation's 

I ; Specfficatkm panel. Click Refresh to reflect changes made - 



External? 



IT 



g?46 



Assefi: Currency Management::Currency Management Func... 



Function 



Assets Currency Management-Currency Management Func... 



Assett: Currency Management::Currency Management Func, 



Assett: Currency fttanagement:Currency Exchange Function... 



Assets: Currency Management::Currency Exchange Function. 



Assett: Currency Management:Currency Exchange Function... 



M Common DataTypes^Deomai-newOperationcCurrencvValu., 



Show Details 



Refresh 



Next> 



Cancel - 
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LogicLibrary Asset Capture Tool 



File ;. View ; Help 




mm 



Capture Worfcflow 



Workflow Details ' ; 



Asset Capture Workflow 
0 Configuration 
SO Definition 
}• 13 Identification 

Overview 
hS Classification 
& [x] Asset Model 
J f Model Capture 
I h-ED Identity Model 
h0 Diagram Option 
I--E1 Interfaces 

h±J Review Diagran 
l O Publish Model 
HI solution 

□ Asset Synonyms 

□ Map 



IE 



The following External Data Types have been determined based on their i- 
use by Externa! Functions. Please mark any additional External Data Types i 
by updating the External Data Types field oh the LogicLinraiytab of ; ^he '-"-If 
Class Specification m the Asset Model. '■■ : y^ 

.'. ; ' : • ' , iv. ,\ ,; ' , / ■ ,; : c ; 'V ,\." 

Click the After Mode* button to view the model, ctick Refresh to update the ; [| 



External? 



E3 



Data Types 



Logical View::Asseft: Current Manageroent.'Currency Man... 



Logical View::Asseft: Current Management::Currency Man... 



^.250 

Alter Model | 



Refresh; 



..... 

fed 



< Back- 



i; Cancel) 
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H C: \Program Fi les\IBM \Visua1 Age fb 



Fde ■: ;Edfc ; View.- Favorites | Too^s .Help 



Ij. ^Back V: "® j| j #t5earch ^Favorites ffifrfctory. 



Module Diagram: Component View/ CurrencyManagement 



I t j CurrencyMa 
nagement 

^y.. !|VV :: 




252 



Currency Management 
Functions 



Currency Exchange 
Functions 



J,!. _V 1 f : 0My Computer . 



- A 
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LogicLibrary Asset Capture Tool 



File , .View 'jHelpk; 



Cglpture Workflow 



Workflow Details 



b-O Asset Capture Workflow 
s- 0 Configuration 
B-Eg Definition 
I U0 identification 
i U0 Oversew' 
I Classification 
[ gi-B Asset Modei 



Solution 



hO Asset Synonyms 

Map 
m~ffl Export 



EJ"0*solution (+) 
ED*overvfew 



arc hitectuaJ-assumptions 



•-□ business-use-case-model 

- □ system-use-case-model 
■ □ business-object-model 
••□ requirements 

supplementary-specification 
~ □analysis-model 
••□ design-model 

- □ implementation-model 

- □ deployment-model 
-□test-model 

physical-Implementation 
□ examples 



Back j ir; N6>?t 



Baok 1 \ 



.Next* 



l! ; j l ;v[..":' \ ' -Cancel . , : 







name 


architectual-assumptionslstrina 


type 




reference 




1 . ilj^uriReference 1 
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LogicLibrary Asset Capture Tool 



File, Vfew Help 



Capture Workflow 



Workflow Details 



B-Q Asset Capture Workflow 
13- 0 Configuration 
&S Definition 
! H3 Identification 
I j-EO Overview 
I Classification 
j Asset Model 
1 H3 Solution 

hiai_ 

©-0 Map 
S-i Export 



The followinQ are aliases that Will iD e used to generate a lternative: i^^drds;fbr: 
the asset The alternate that a search of the 

library will find your assets/ Please add or remove aliases as necess ary. Note 
that the aliases should he- |h priority order,, \.-^y i:.V^v':^ , nj'i> 1 NO*: 



Enabled 


1 / V'$? AssfctTerro , ' : , f 


' : Synonym ?j '•..!. v ,'j 


B ■ 


Currency 

. ■ ■ ■■• — 1 :' , 'r,: i, "t ■ — : — — — —.-r 


Money 



'i:.;^Acid; ; 



< BacK 



; i r :"-V:'|VjeXt^ 



Delete 



Cancel 
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LogicLIbrary Asset Capture Tool 



File View Help 



mmmmmmm: c 



Capture Workflow 



Workflow Details 1 



Asset Capture Workflow 
"0 Configuration 
0 Definition 
0 Identification 
2 Overview 
. 0 Classification 
&~0 Asset Model 
H9 Solution 
■0 Asset Synonyms 
•0 Ma p 

i EH i Bf af arati JSIBBBHl 

j-O Library/DRM Synot 
K3 Data Types 
L -D Functions 
"H Export 



s-D 

B 

f 



B- 



B' 



The Mapping step helps evaluate an Asset against an Idealized Ccm}>onent 
Model. Please select the Weahzed Component ModeKs) which best 
describe the' Asset ' [ \X t . ,; ! * V. * - s,; * .."i ; 'y:*: : ; : 



El-Reference Model 

B-*p C:\Program Files\LogicUbrary\assetStore\Demo\\drm\drm.mc 
KJ-Eqjava 
EB-E3 LogicLibrary 
a-Ea Demo 

®-*& Currency Management DataTypes 
ffl-£J Currency Management 
s-Q Currency Management Functions 
s-H Currency Exchange Functions 
E-Eq Common DataTypes 



currency Manaaement 



J_JL 



Details View Model 



< Back 



Next > ; 



Cancel. 
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LogicLibrary Asset Capture Tool 



wFile View Help 



Capture WorkHoW: 



Workflow Details 



B-D Asset Capture Workflow 
Configuration 
B-0 Definition 

Identification 
- s3 Overview 
3 Classification 
Asset Model 
_ Solution 
p. 0 Asset Synonyms 
B~0 Map 

1 M Reference Model 
□I 



a- 



Thefollowins are synonyms defined for your enterprise and the selected f ; 
reference model. While you can add or delete Asset Synonyms, you can only ; 
disable Enterprise .and- Reference Mode} aMa^ses! ".; : r ■ ; i; jj. 



Libra ty Synonyms 



Library/DRM Synor 



HQ Data Types 
L O Functions 
Eh® Export 



L2Q 



; Enabled 



0 



□ 



Asset Term 



Currency : 



Schedule 



'Syhonyrh! 



Money; 



Time 



Reference Model SfyWonyrris' 



.Enabled 



Asset Term 



DRMTerm 



Synonym * 



DRMTermAlias 



< Back 



Next> 



Cancel- ';' 
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LogicLibrary Asset Capture Tool : 



File View Help 



Capture Workflow 



b Q Asset Capture Workflow 
4i~0 Configuration 
B-0 Definition 

0 Identification 
3 Overview 
3 Classification 
3 Asset Model 
0 Solution 
-0 Asset Synonyms 
0Map 

1 0 Reference Model 

Library/DRM Synoi 



I" 



Data Types 



Functions 
sHU Export 



Workflow Details 



FT 



Asset Item 



ERest 

Eg-B Currency Mana gement 



turrencyvafu 



254 



258. 



Details!':; f 



IC Item 



B-Reference Model 
H~Bl 



258 



256 



Details 



ipiQhow Suggestions 1: Map 



260 



Mapping info rmation 
Current Mappings 



urrent Mapping* 



< Back 



;;/i|'v' : .0ffffe;. of If.-," iDat^il'S 



» Next * 



Cancel 
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Logic Library Asset Capture Tool 



File ; View Help 



mm 



Capture Workflow 1 



Workflow Details 



B-O Asset Capture Workflow 
is 0 Configuration 
B--0 Definition 
j~0 Identification 

f 0 Overview ; ; 

j~0 Classification 
E-0 Asset Model 
H3 Solution 
0 Asset Synonyms 
(p-0 Map 

" 0 Reference Model 
0 Ubrary/DRM Synoi 

□ Functions 
Export 



r"' \ ■•; •'. ! 1 :■ " ■ ' ; Asset Item ! " : - 


■ - icitem ' yfi 

j.^.. — , — ■ .„......._ _ —^.ll, 


B-test 

Currency Management 
258 x 254 


1 B-Reference Model 

I a B BBIB5BSBBE 

1 258^ 256 


;< . : < " ; . ^ r *W* vf.' 
j /;.:;•;* . j»; Details- |" ,., ,,; 


ijf ?;'"p ■" v f Details'" ' 


• .153 Show Suggestions /Map 



Mapping Information 



additional-data 


true 


affinity 


5 


notes 


whvl chtose these values . ._ 1) Ci- 


partial-data 


trus. 
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\ 'File' . View ''Heip ; . :; -.j ,• ;• ; .' • '." \;V; 



Capture Workflow . . : . i; 




Q-D Asset Capture Workflow | 
da-El Configuration 
B-El Definition 
I ["-0 Identification j 
-0 overview j 
J r-El Classification | 
1 H~ El Asset Model 
j H3 Solution 
|--E1 Asset Synonyms 
b~E1 Map 

j t~ E) Reference Model 1 
1 r* El Library/DRM Synoi ! 

! l.q Functions ; 
s~[x] Export j 


\\ ' ■ Asset Item , ■><■ ■ ';.■,/;:' ;•'! 




[ B~test 

bb~E3 Currency Management 

( 258^ 254 


B Reference Model 

CurrencyValue 

258^ ?56 




iV- 1 ' " ; ; .• ;|;, 'Details 1 ; , '. ' "" , ; 


•'•'*'"I ' . .'!;,V'.'"" ; "f5? Show Suggestions; Jtj Map V: \ •'/<, ."'i/ /;■/ i' 


•': , \. ' ; ° ' v ] i ■ ■■ • 'Mapping Information: .. • •■ •;. '. ■ '-: - ; - T-'-' 

.;>•-': Y !''V , 'v;... 1 "''- : j.; ■ v - * * ; ' .Current Mapping* • • \% v 'i'; 'i ' '!•' : 'T/'!c- 
iP(p Current Mappings [ *™ " ~~ " ' " 
fr*S CurrencyVaiue 


S-! ; .•■'.:fi«;. ■•• 1 •'>• r ',i iv'Aj-' 1 Delete - f j 


!•/ . Details.' ", J ; /* V: . £j . , ! ' •• ;;f • .i>; . ; 




<8ack Next> ; 1 Cancel ' 
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IS ICS Detail • Microsoft Internet Esplofer 



i?e. : .£* .' Visw ; f^otiiet ;Ioo!e; Help* 



Search Categories frjfi: 



SEARCH 



LoglcLlbrary W»b. 



Information Ctntor 



Support C^fttar 



TCS 



TAQS 



Organrntional Gttmflt 



At$ttVle^ 



Profite* 



Prefect; . 



Users 



4~ TCS Detail 



Non-FMnctionaf 
Requirement S»U 



280 



see 



{ 



Delete ] [ gave A?' | [Run | , 



Project 

Project Manager 
Description 



Finance Project 
Joe Williams 
Account reporting 



TCS Name CurrConv 

Description Currency Conversion 

Status Active 

DRM IndUfelnsDRMSample 

Create Date Tue May 01 16:09:59 CDT 2001 

Last Modified Date Tue May 01 16:09:59 CDT 2001 



Nonfunctional Requirements 



Target Functions 1 r .' ; ,»' ; •.>.* •• V •,• 'Edit--' ■ 

Function Name Weight 
PoJ/cyRecordManagemerrt:PolicyRecordFunctions:GetNfWStatus 5 
CurrencyManagement:CurrencyExchangeFunctions:addExchangeRate 5 
ntdlinutknull 5 



Scoring Parameters;. ;. ., 
Asset level affinity threshold 
Function level affinity threshold 
Allow functions with partial functionality 
. Allow functions with additional functionality 



50 • 



Yes 
Yes 



} 



-282 
284 



J if 
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! H Asset Query Specification - Microsoft Internet Fxplorei 








MSB 








^fS6 





Search Categories £rj 



tnfornrMttfon tfonbr 



Support Center 



TCS 



TAOS 



Asstt Views 



Profiler 



Prolects 



Users 



Ncm-FunctSoniil 
Requirement Sets- 



icsmos Statu* 



Logic Library 

SITE SEARCH | Si lb MAP J FEEDBACK J MANAGE MY PROFILE { LOGOUT 



+ Asset Query Specification 



j Ruin j j §a\7e As j [jfe^tevj , r 



Project Finance Project 

Project Manager Joe Williams 
Description Account reporting 



TAQS Name CurrConv 

Description Currency conversion 

Status Active 

Create Date 04yD5/D1 

Last Modified Date ' 04/05/01 



Non-Functional Requirements 



Edit 



Asset Search Criteria 

Asset name Currency AND Euro 

Function name ' Currency AND Euro 



Edit 



Attached Assets; ' 

Asset Name Asset Version 

Assail 1.0 



Asset Description 

Asset 1 Description 



|;7j 
"Li 



Supplier 

Vendor 1 ^ 
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msmmm 



raiiiH 



Swr* F4w*t««' ;KSsto© :| 



QjKUM: . 



Saarch Categories 



SEtftCH 



f Model Based Query Results 



Pf ojtcti 



Won«FuncHoM! • 
RMjuIrtmtwtStti ' 



P? 



Nama , 

TaxBridge 



Vanlon .Dttcriptlon 



L }JLjJ&HBk± :J?<_ 

285 



Tefjwo<U»PrryacyPoScy 



Tool far life insurance companies to administer policy 
level taxation in a compliant manner 

Hertdlas curfincy etthjingi ttmctianatity 1 

Organizes product irjformation (categories, product 
delatle.trass-seJIinfo.elc.) 



Suppllir 

Practical 
Computing, fi 

IBM ' . ' 
IBM 



Tjpa ' 

BIB 



library 
A 

: A • ' 
A 



Affinity 
Scare 



100 


'£ .: 


30',':. 


'1 


70 






I s : 










r 








I-. 








b 
t 



XISS 



J 
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H 7CS .Detail • Micro jolt lnletnel Explorer 



DRM IndlJfelnsDRMSample 
Create Date 04/0501 
last Modified Date 04/0501 



i Non-Functional Requirements 1 

' Target Functions • , 
Function Name 



Edit 



Edit J ■ 
Weight 



re 



DateiminsFederalWithhoMin 9 




PolicyRecordManagement:PolicyRecordFt]ncttons:8etTaxlDNumber 


3 




( Scoring Parameters ; •;• *V V\"' l ; > '." ; :' 


•r,< ••. 

.. r-i 




Asset level affinity threshold 50 






Function level affinity threshold ; 9 






Allow functions with partial functionality Yes 






Allow functions with additional functionality Yes 






Attached Assets v ;: • ; ;\ * \ t „. ; ' ■ j .. 




, r . ' ... ■ ,* •} 


Name Version Description Supplier 


Type 


Library 




JSP 




Organizes product information 
Product Catalog 1,1 (categories, product details, IBM 
cross-sell info, etc.) 


JSP 


A 


.'• "I ■ T • ' toblfbr.fiTe insurance companies' J • - 


: ejb v; ; 




[ WMe | |.;:s<jy.e As J fR«n;| 
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Hi Asset Detail Miciosofl Internet Explore! 



LagicLibrary 



SITE SEARCH i SlFF MA° ; FEEDBACK MANAGE MY PROFjlE j LOGOUT 



■ SEARCH V[ h ; ■ j Asset Name 



Currency Exchange 

Handles currency exchange functionality 



Information Canttr 



Type 



res rr'r~:-v::-i 



Oii^^bi^Groupil Gen8ral 



Descriptors 

Operating System 



UNIX 



Asset Views 



Project 



^on-Functibn*r 



83? Sys,em 



i ; -Functions V\\J~';;0V>. •"!;;»;' ; -V ,.^ : ;-V . ' ^' " ; 
convertQ Converts a currency value to a new currency 

updateExchangeRatesQSets new currency conversion factors 



TCSfTAQS Status f 



•r 



Financial Assets Great Asset, High Cost. 

Operational Assets Support has been an issue in the past. 



Artifacts 



T Acquire '■ 



Test Drive 



111 



Mg. so 
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Out to Project Manager 
Approval Workflow 




302 



314 



JL 



Asset Acquisition 
Requested by Actor 



Asset is Associated 
to Project Asset License 
Record is stored with 
a status of 
"Pending Project 
Manager Approval" 



Project Manager is 

notified 
via eMail of a new 
Acquisition request 




Append a note to the 
request that this is a re- 
request of a previously 
rejected request 
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| 5 pm_f".ome • MicroioU Internet Explorer 




I"- 0e ,' W> I Jfew," footer : ' : Id9fe ; ';H^ V ~ 7 ; \ '/ '"• v' ' :7 ''" 





Search Categories £1; 



Support C»ntt7 "'7 j 



Profile* 



TCSffAas Status' 1 



Logic Library 



StT£ SEARCH SUPMA^ FEEDBACK MANAGE MY PROFILE j lOGOJT 



1 

2 

3 

4 
5 
6 



330 



Requester 
name 


Requesting 
Project : : 


Asset name Version 


Asset tfesc 1 


Note , 




' Carol McGrath Project 1 


Cunency 
Exchange 


V1.0 


Manages cunencies and 
exchange rates 


This 

component... 


r 


Angela Hanafin Project 2 


Product 
Catalog 


VIA 


Organizes information about 
items for sale. 


Notes 2 


r 


Name 3 


Project 3 


Customer 
Profile 


V1.0 


Manages information about 
customers. , 


Notes 3 


r 


Name 4 


Project 4 


Asset 4 


VI .0 


This is Asset 4 


Notes 4 


r 


Name 5 


Projects 


Assets 


VI .0 


This is Asset 5 


Notes 5 


r 


Name 6 

\ 

0 318 


Projects 

V 

320 


Assets 

V 

322 


Vt.Q This is Asset 6 ' 

^324 ^326 


Notes 6 

^328 


r 




•'^ttflfB^tompan^deas 




1 



•52001 LogfcLtorary, tnc AS rights rsswvad. 
Terms of Use Privacy PcEcy 



ii_ 
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Asset Name: 
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establish the publication date of another citation or other special reason (as 
specified) 

"O n document referring to an oral disclosure, use, exhibition or other means 

W P" document published prior to the international filing date but later than the 
priority date claimed 



a T" later document published after the international riling date or priority 

date and not in conflict with the application but cited to understand the 
principle or theory underlying the invention 

"X" document of particular relevance; the claimed invention cannot be 

considered novel or cannot be considered to involve an inventive step 
when the document is taken alone 

" Y M document of particular relevance; the claimed invention cannot be 

considered to involve an inventive step when the document is 
combined with one or more other such documents, such combination 
being obvious to a person skilled in the art 
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Box I Observations where certain claims were found unsearchable (Continuation of Item 1 of first sheet) 



This international report has not been established in respect of certain claims under Article 17(2)(a) for the following reasons: 

1. d Claim Nos.: 

because they relate to subject matter not required to be searched by this Authority, namely: 



I | Claim Nos.: 

because they relate to parts of the international application that do not comply with the prescribed requirements to such 
an extent that no meaningful international search can be carried out, specifically: 



3. m Claim Nos.: 

because they are dependent claims and are not drafted in accordance with the second and third sentences of Rule 6.4(a). 
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This International Searching Authority found multiple inventions in this international application, as follows: 
Please See Continuation Sheet 



1. ixxl As all required additional search fees were timely paid by the applicant, this international search report covers all 
searchable claims. 

As all searchable claims could be searched without effort justifying an additional fee, this Authority did not invite 
payment of any additional fee. 

As only some of the required additional search fees were timely paid by the applicant, this international search report 
covers only those claims for which fees were paid, specifically claims Nos.: 



No required additional search fees were timely paid by the applicant. Consequently, this international search report is 
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BOX II. OBSERVATIONS WHERE UNITY OF INVENTION IS LACKING 

Group I, claim(s) 1-11 and 33 - 40 are drawn to an asset capture software utility with a special technique of mapping software 
resources to a domain reference model. 

Group II, claim(s) 12 - 32 are drawn to a repository to store artefacts with a special technique of a asset source to generate software 
assets having metadata that reference the artifacts and a asset management system to receive the software asset from the asset source. 

The inventions listed as Groups I and II do not relate to a single general inventive concept under PCT Rule 13.1 because, under PCT 
Rule 13.2, they lack the same or corresponding special technical features for the following reasons: 

The special technical features of Group I, mapping software resources to a domain reference model, are not found in technical features of 
Group II and the special technical features of Group n, an asset source to generate software assets having metadata that reference the 
artifacts and a asset management system to receive the software asset from the asset source, are not found in technical features of Group 
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